Electronic management of patient health care data

ABSTRACT

Various embodiments manage access to patient health-related information in a health care patient portal. In one embodiment, a determination is made that a user has accessed the health care patient portal. A set of electronic health-related records associated with the user is identified. A source identifier associated with each record is also identified. The source identifier is associated with an entity that provided the electronic health-related record to the health care patient portal. A sharing status associated with each record is determined. The sharing status indicates that the associated electronic health-related record is one of sharable and non-sharable with an entity other than the user. The records are presented to the user in the health care patient portal. A least one record is presented with the source identifier and the sharing status associated with the record.

BACKGROUND

The present disclosure generally relates to the electronic management ofpatient health-medical data, and more particularly relates to managingand presenting patient health-medical data from different types ofsources in a patient health care portal.

Health care providers have traditionally maintained all of theirpatients' information in paper filing systems. However, this practice isvery inefficient and lends itself to poor management practices of thepatient's data. Accordingly, Electronic Health Management Systems (EHMS)have been developed to provide many of the functionalities and featuresof paper filing systems in an electronic paperless format. These systemsstreamline workflow processes and clinical, financial, andadministrative information. Electronic Health Management Systems alsoimprove coding and billing accuracy. However, patients generally do nothave access to EHMSs to manage and provide their health-related data.

BRIEF SUMMARY

In one embodiment, a method for managing access to patienthealth-related information in a health care patient portal is disclosed.The method comprises determining, by an information processing systemcomprising a health care patient portal, that a user has accessed thehealth care patient portal. A set of electronic health-related recordsassociated with the user is identified. A source identifier associatedwith each of the set of electronic health-related records is alsoidentified. The source identifier is associated with an entity thatprovided the electronic health-related record to the health care patientportal. A sharing status associated with each of the set of electronichealth-related records is determined. The sharing status indicates thatthe associated electronic health-related record is one of sharable andnon-sharable with an entity other than the user. The set of electronichealth-related records is presented to the user in the health carepatient portal. The at least one of the set of electronic health-relatedrecords is presented with the source identifier and the sharing statusassociated with the at least one of the set of electronic health-relatedrecords.

In another embodiment, an information processing system for managingaccess to patient health-related information in a health care patientportal is disclosed. The information processing system comprises memoryand a processor communicatively coupled to the memory. The informationprocessing system also comprises a health care patient portal and aportal manager. The portal manager is configured to perform a method.The method comprises receiving, from a at least one source, a set ofelectronic health-related records associated with at least one user. Asource identifier is assigned to each of the set of electronichealth-related records identifying the source as one of the user basedon receiving the set of electronic health-related records an entityintegrated with the health care patient portal, and an entity that failsto be integrated with the health care patient portal. A determination ismade that the user has accessed the health care patient portal. The setof electronic health-related records associated with the user isretrieved. The source identifier associated with each of the set ofhealth-related records is identified. A sharing status associated witheach of the set of health-related records is determined. The sharingstatus indicates that the associated electronic health-related record isone of sharable and non-sharable with an entity other than the user. Theset of electronic health-related records is presented to the user in oneor more user-customizable widgets within the health care patient portal.At least one of the set of electronic health-related records ispresented with the source identifier and the sharing status associatedwith the at least one of the set of electronic health-related records.

In yet another embodiment, a computer program storage product managingaccess to patient health-related information in a health care patientportal is disclosed. The computer program storage product comprisinginstructions configured to perform a method. The method comprisesdetermining, by an information processing system comprising a healthcare patient portal, that a user has accessed the health care patientportal. A set of electronic health-related records associated with theuser is identified. A source identifier associated with each of the setof electronic health-related records is also identified. The sourceidentifier is associated with an entity that provided the electronichealth-related record to the health care patient portal. A sharingstatus associated with each of the set of electronic health-relatedrecords is determined. The sharing status indicates that the associatedelectronic health-related record is one of sharable and non-sharablewith an entity other than the user. The set of electronic health-relatedrecords is presented to the user in the health care patient portal. Theat least one of the set of electronic health-related records ispresented with the source identifier and the sharing status associatedwith the at least one of the set of electronic health-related records.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The accompanying figures where like reference numerals refer toidentical or functionally similar elements throughout the separateviews, and which together with the detailed description below areincorporated in and form part of the specification, serve to furtherillustrate various embodiments and to explain various principles andadvantages all in accordance with the present disclosure, in which:

FIG. 1 is a block diagram illustrating one example of an operatingenvironment according to one embodiment of the present disclosure;

FIG. 2 is a block diagram illustrating a detailed view of a patientportal manager according to one embodiment of the present disclosure;

FIG. 3 shows one example of an electronic record according to oneembodiment of the present disclosure;

FIG. 4 shows one example of a facility profile for a patient portalaccording to one embodiment of the present disclosure;

FIG. 5 shows one example of a subscriber profile for a patient portalaccording to one embodiment of the present disclosure;

FIG. 6 shows one example of a user profile for a patient portalaccording to one embodiment of the present disclosure;

FIG. 7 shows one example of a patient portal displaying a home sectionto a user according to one embodiment of the present disclosure;

FIG. 8 shows one example of a patient portal displaying a clinicalsummary section to a user according to one embodiment of the presentdisclosure;

FIG. 9 shows one example of a patient portal displaying a messagingsection to a user according to one embodiment of the present disclosure;

FIG. 10 shows one example of a patient portal displaying an appointmentsection to a user according to one embodiment of the present disclosure;

FIG. 11 shows one example of a patient portal displaying a medicationsection to a user according to one embodiment of the present disclosure;

FIG. 12 shows one example of a patient portal displaying a doctormanagement section to a user according to one embodiment of the presentdisclosure;

FIG. 13 shows one example of a patient portal displaying an emergencycontact section to a user according to one embodiment of the presentdisclosure;

FIG. 14 shows one example of a patient portal displaying a recordssharing section to a user according to one embodiment of the presentdisclosure;

FIG. 15 shows one example of a patient portal displaying authenticationcredentials for a health care provider to access the patient portal toview a patient's health-related data according to one embodiment of thepresent disclosure;

FIG. 16 shows one example of a patient portal displaying an emergencymedical records section to a user according to one embodiment of thepresent disclosure;

FIG. 17 shows one example of a patient portal displaying a medicalportfolio section to a user according to one embodiment of the presentdisclosure;

FIG. 18 shows one example of a patient portal displaying a documentsection to a user according to one embodiment of the present disclosure;

FIG. 19 shows one example of a patient portal displaying a record view,download, and transmit section to a user according to one embodiment ofthe present disclosure;

FIG. 20 is an operational flow diagram illustrating one example of anoverall process for managing access to patient health-relatedinformation in a health care patient portal according to one embodimentof the present disclosure;

FIG. 21 is an operational flow diagram illustrating another example ofan overall process for managing access to patient health-relatedinformation in a health care patient portal according to one embodimentof the present disclosure;

FIG. 22 is a block diagram illustrating one example of an informationprocessing system according to one embodiment of the present disclosure;and

FIG. 23 shows one example of the structure and format of a continuity ofcare document (CCD).

DETAILED DESCRIPTION

Operating Environment

FIG. 1 illustrates one example of an operating environment 100 accordingto one embodiment of the present disclosure. The operating environment100, in this embodiment, comprises a plurality of information processingsystems 102, 104, 106, 108, 110 communicatively coupled to one or morenetworks 112. The information processing systems 102, 104, 106, 108, 110comprise server systems, user systems, and/or the like. Examples of usersystems include (but are not limited to) desktop computers; servers;portable computing devices such as laptop computers mobile/smart phones,tablets, wearable computing devices (e.g., smart watches), personaldigital assistants, etc.; and the like. In one embodiment, one or moreof the information processing systems 102, 104, 106, 108, 110 are partof a cloud-computing environment or a non-cloud computing environment.

The network(s) 112 comprises a local area network (LAN), a general widearea network (WAN), and/or a public network (e.g., the Internet). Thenetwork(s) 112, in one embodiment, also comprises a wirelesscommunication network that supports any wireless communication standardsuch as, but not limited to, a Wireless Fidelity (WiFi) network, GlobalSystem for Mobile Communications (GSM), Code Division Multiple Access(CDMA), Time Division Multiple Access (TDMA), General Packet RadioService (GPRS), Frequency Division Multiple Access (FDMA), OrthogonalFrequency Division Multiplexing (OFDM), or the like. The wirelesscommunication network includes one or more networks based on suchstandards. For example, in one embodiment, the wireless communicationnetwork comprises one or more of a Long Term Evolution (LTE) network,LTE Advanced (LTE-A) network, an Evolution Data Only (EV-DO) network, aGPRS network, a Universal Mobile Telecommunications System (UMTS)network, and the like.

At least one system 102 comprises a patient portal 114. The patientportal 114 is a health care-related website and/online application(e.g., a cloud-based application) or service (e.g., a cloud-basedservice) that allows patients (also referred to herein as “patients”) tosecurely manage and view their health information created by one or morehealth care providers (e.g., physicians and hospitals) and/or providedby the patient. It should be noted that throughout this disclosurehealth-related information comprises medical-related information andvice versa, unless otherwise noted.

The patient portal 114 also allows a registered patient to securelyinteract and communicate with their health care providers. In oneembodiment, the patient portal 114 comprises an interactive environment116 and a patient portal manager 118. The patient portal manager 118comprises a profile manager 202 (FIG. 2), a data presenter 204, a dataencryption/decryption module 206, and a communication manager 208. Thepatient portal 114 further comprises user profiles 120, facilityprofiles 122, subscriber profiles 124, and user health-medical data 126stored within one more electronic records 128. Each of these componentsis discussed in greater detail below.

In one embodiment, at least a second of the system 104 comprises anelectronic record management system such as an Electronic HealthManagement System (EHMS) 130. It should be noted that an EHMS 130 canalso reside on a user system 106 and/or within a local networkcomprising a user system 106. An EHMS 130 comprises and/or is based on,for example Electronic Medical Record (EMR) Systems, Electronic HealthRecord (EHR) Systems, Personal Health Record (PHR) Systems, PracticeManagement Software Systems, Health Information Exchanges (HIEs), anddevice and software vendors systems in the patient health carecontinuum.

The EHMS 130 comprises an interactive environment 132 that allows healthcare professionals to interact with the EHMS 130 via one or moreinterfaces 134 (e.g., applications, user interfaces, web browsers,and/or the like) residing on their user system 106. In one embodiment,the EHMS user system 106 and its users are associated with a facilitysuch as a physician's office, a hospital, an imaging center, alaboratory, and/or the like. A single EHMS 130 can be associated with asingle facility or multiple facilities. The EHMS 130 further comprises,among other things, patient health-medical data 136, a messaging module138 (e.g., an email application, a Short Message Service (SMS) messagingapplication, a Multimedia Messaging Service (MMS) messaging application,a network adapter, and/or the like) and a patient portal communicationinterface 140, which implements an application programming interface(API) for the patient portal 114.

The communication interface 140 can be part of the messaging module 138or separate from the messaging module 138. In another embodiment, themessaging module 138 is not required and the communication interface 140performs the same functions as the messaging module 138. The patientportal communication interface 140 enables the EHMS 130 to securelycommunicate with the patient portal 114. The patient health/medial data136, in one embodiment, is stored within one or more electronic records142, which are maintained within one or more databases 144. Thedatabase(s) 144 can be part of the EHMS 130, separate from the EHMS 130,reside on the system 104, and/or reside on or across one or more remoteinformation processing systems.

The EHMS 130 allows a user such as a health care provider to create andmanage electronic records 142 for his/her patients. Examples ofelectronic records 142 include EMRs, EHMS, PHRs, records generated byPractice Management Software Systems, records generated by HIEs, and/orany other types of electronic records generated within the patienthealth care continuum. It should be noted that the terms “ElectronicHealth Records” and “Electronic Medical Records” can be usedinterchangeably. EHMS and EMRs are systematic collections of electronichealth information associated with a specific individual (patient) orpopulation. An EHR comprises various types of information such aspatient medical history, immunization status/history, lab results,medication and allergy information, radiology images, vital signs,personal statistics (e.g., age, weight, and height), demographics,billing information, and/or the like.

An EHR/EMR can be a patient created in hospitals and ambulatoryenvironments using an Electronic Health Management System (EHMS) 130either on the network residing locally at the hospital or ambulatoryenvironment who created the record. An EHR/EMR is generally an internalrecord generated and maintained within an institution to give patients,physicians and other health care providers, employers, and payers orinsurers access to a patient's medical records across facilities. AnEHR/EMR software vendor produces software to manage Electronic HealthRecords for the health care providers use. A PHR is an online accessiblehealth record that is maintained by the patient and comprises healthdata and information related to the care of the patient. The patientgenerally provides the information to be maintained by a PHR.

In one embodiment, an EHMS 130 comprising a patient portal communicationinterface 140 is referred to as an “integrated partner”, an “integratedsubscriber”, and/or as being “integrated” with the patient portal 114.Also, a facility and/or provider that utilizes an EHMS 130 that isregistered/integrated with the patient portal 114 is also referred to asan “integrated partner”, an “integrated subscriber”, and/or as being“integrated” with the patient portal 114. However, embodiments of thepresent disclosure are not limited to integrated EHMSs, facilities, andproviders. The patient portal 114 is also able to communicate withnon-integrated EHMSs, facilities, providers. For example, FIG. 1 showsone or more information processing systems 110, which can comprise anEHMS and/or be an EHMS user system. These systems 110 comprisepatient-related health-medical data 146 stored within one or morerecords 148, images, and/or the like. These systems 110 also compriseone or more interfaces 150 (e.g., applications, user interfaces, webbrowsers, and/or the like). A patient portal communication interface 140does not reside on these systems and, therefore, these systems areconsidered to be not integrated with the patient portal 114. However,these systems 110 are able to utilize one or more of their interfaces150 to transmit and receive unstructured, semi-structured, and/orstructured data to/from the patient portal 114, as will be discussed ingreater detail below.

As discussed above, one or more health care professionals interact withthe EHMS 130 via one or more interfaces 134 on an EHMS user system 106.In particular, health care professionals interact with the interactiveenvironment 132 of the EHMS 130 to enter, store, and manage variousmedical and health related data/information associated with a givenpatient. For example, the health care professional can enteradministrative and billing data, patient demographics, progress notes,vital signs, medical histories, diagnoses, medications, immunizationdates, allergies, radiology images, lab and test results, and/or thelike into the EHMS 130. The EHMS 130 generates and maintains at leastone electronic record 142 for the identified patient/user based on thedata entered.

FIG. 3 shows one example of an electronic record(s) 342 generated by theEHMS 130 and displayed to a health care professionals interacting withthe interactive environment 132. In this example, the electronicrecord(s) 342 is an EHR. However, the EHMS 130 is not limited to onlygenerating EHMS and can generate any type of electronic recordassociated with a patient. FIG. 3 shows the interactive environment 132being displayed to the health care professional via the interface 134 onhis/her system 106. Within the interactive environment 132, an EHR 342is displayed to the health care professional. The EHR 342 comprises afirst portion 302 displaying general patient data such as patient name304, patient age 306, patient gender 308, patient insurance 310, patientprimary care physician 312, and various other types of data. At least asecond portion 314 of the EHR 342 displays either all of thehealth-medical related information associated with the patient ordisplays a portion of this information as selected by the health careprofessional. In the example shown in FIG. 3, the EHR 342 displays apatient summary comprising various types of medical/health relatedinformation such as past medical history 316, past surgical history 318,current medication 320, allergy information 322 social history 324,family history 326, and/or the like.

Communicating with the Patient Portal

In one embodiment, the EHMS 130 is communicatively coupled to thepatient portal 114 such that the EHMS 130 is able to send and receivemessages to/from the patient portal 114, transmit electronic records 142and other data to the portal 114, and/or the like. In one embodiment,the EHMS 130 has been previously been registered with the patient portal114 and is associated with a subscriber profile 124 for the portal 114.FIG. 4 shows various examples of subscriber profiles 124. In the exampleshown in FIG. 4, each row 402, 404, 406 in the table 400 corresponds toa subscriber profile. It should be noted that in other embodiments, eachsubscriber profile 402, 404, 406 is stored separate from one another.The table 400 comprises a plurality of columns, each storing a differentset of information. In this example, the table 400 comprises a firstcolumn 408 entitled “Subscriber ID”; a second column 410 entitled“Login”; a third column 412 entitled “Password”, a fourth column 414entitled “Address”; a fifth column 416 entitled “Contact”; a sixthcolumn 418 entitled “Billing Data”; a seventh column 420 entitled“Patients”; and an eighth column 422 entitled “Facility ID”.

The “Subscriber ID” column 408 comprises entries 424 uniquelyidentifying the EHMS associated with the subscriber profile. The “Login”column 410 comprises entries 426 with the unique login or user nameassigned to the EHMS for interacting with the patient portal. The“Password” column 412 comprises entries 428 with the unique passwordassigned to the EHMS for interacting with the patient portal 114. The“Address” column 414 comprises entries 430 with the address of the EHMS.The “Contact” column 416 comprises entries 432 that identify the contactperson at the EHMS who manages the EHMS's account with the patientportal 114. The “Billing Data” column 418 comprises entries 434 withvarious types of billing data associated with the EHMS (if applicable).Examples of billing data include subscription plan type, paymentinformation, payment histories, and/or the like. The “Patients” column420 comprises entries 436 with the patient ID (or a pointer to the userprofile 120) of each patient associated with the EHMS. The “Facility ID”column 422 comprises entries 438 with the subscriber ID of thefacilities associated with the EHMS 130. It should be noted that one ormore of the columns and entries shown in FIG. 4 are optional, andadditional information can be included within a subscriber profile 124as well.

In one embodiment, when the EHMS 130 wants to communicate with thepatient portal 114 the communication interface 140 establishes asecured/authenticated link with the patient portal 114. In one example,the communication interface 140 provides authentication information viathe communication interface 140 to the portal 114 to obtain a securitytoken for that session period. For example, the communication interface140 of the EHMS 130 sends the following message to the patient portal114:

<?xml version=″1.0″ encoding=″utf-8″?> <soap12:Envelopexmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″xmlns:xsd=″http://www.w3.org/2001/XMLSchema″xmlns:soap12=″http://www.w3.org/2003/05/soap-envelope″>  <soap12:Body>  <AuthenticateInterface xmlns=″http://tempuri.org/″>   <FacilityId>long</FacilityId>    <UserLogin>string</ UserLogin>   <Password>string</Password>   </AuthenticateInterface> </soap12:Body> </soap12:Envelope>

This message/request includes the identifier of the facility (e.g.,health care provider) associated with the transmission, the loginassociated with the facility for the patient portal 114, and thepassword associated with the facility for the patient portal 114. Itshould be noted that authentication request/message received from theEHMS 130 can include any type of information that allows the patientportal to identify the facility and/or EHMS 130 associated with therequest. The patient portal 114 receives this message and thecommunication manager 208 analyzes a set of facility profiles 122 todetermine if the requesting facility has been previously registered.FIG. 5 shows various examples of facility profiles 122. In the exampleshown in FIG. 5, each row 502, 504, 506 in the table 500 corresponds toa facility profile. It should be noted that in other embodiments, eachfacility profile 502, 504, 506 is stored separate from one another. Thetable 500 comprises a plurality of columns, each storing a different setof information. In this example, the table 500 comprises a first column508 entitled “Facility ID”; a second column 510 entitled “Login”; athird column 512 entitled “Password”, a fourth column 514 entitled“Address”; a fifth column 516 entitled “Contact”; a sixth column 518entitled “Billing Data”; a seventh column 520 entitled “Patients”; aneighth column 522 entitled “Subscriber ID”; and a ninth column 524entitled “Log Data”.

The “Facility ID” column 508 comprises entries 526 uniquely identifyingthe facility (e.g., physician's office, hospital, etc.) associated withthe facility profile. The “Login” column 510 comprises entries 528 withthe unique login or user name assigned to the facility for interactingwith the patient portal. The “Password” column 512 comprises entries 530with the unique password assigned to the facility for interacting withthe patient portal 114. The “Address” column 514 comprises entries 532with the address of the facility. The “Contact” column 515 comprisesentries 534 that identify the contact person at the facility who managesthe facility's account with the patient portal. The “Billing Data”column 518 comprises entries 535 with various types of billing dataassociated with the facility (if applicable). Examples of billing datainclude subscription plan type, payment information, payment histories,and/or the like. The “Patients” column 520 comprises entries 538 withthe patient ID (or a pointer to the user profile 120) of each patientassociated with the facility. The “Subscriber ID” column 522 comprisesentries 540 with the subscriber ID of the EHMS 130 associated with thefacility. The “Log Data” column 524 comprises entries 542 with varioustypes of log data such as a record of patient logins for the facilities,the time and date of a patient login, and/or the like. It should benoted that one or more of the columns and entries shown in FIG. 5 areoptional, and additional information can be included within a facilityprofile 122 as well.

In another embodiment, the authentication request/message received fromthe EHMS 130 includes information associated with the EHMS 130 inaddition to or in place of the facility information. For example, theauthentication request/message comprises an identifier of the EHMS 130associated with the transmission, the login associated with the EHMS 130for the patient portal, and/or the password associated with the EHMS 130for the patient portal. The patient portal 114 receives this message andthe communication manager 208 analyzes a set of subscriber profiles 124to determine if the requesting facility has been previously registered.

The communication manager 208 analyzes the facility profiles 122 (and/orsubscriber profiles 124) to determine if any of the profiles comprises afacility ID (and/or EHMS ID) matching the facility ID (and/or EHMS ID)within the authentication request message. If a match exists, thecommunication manager 208 further analyzes the profiles 120/124 todetermine if the user name or login information transmitted within theauthentication request message matches the information within theidentified facility profile 122 (and/or subscriber profile 124). Basedon this analysis, the communication manager 208 transmits a responsemessage back to the EHMS 130 via the communication interface 140 eithergranting the authentication request or denying it. For example, thecommunication manager 208 sends the following message to the EHMS 130:

<?xml version=″1.0″ encoding=″utf-8″?> <soap12:Envelopexmlns:xsi=″http://www.w3.org/2001/XMLSchema-instance″xmlns:xsd=″http://www.w3.org/2001/XMLSchema″xmlns:soap12=″http://www.w3.org/2003/05/soap-envelope″>  <soap12:Body> <AuthenticateInterfaceResponse xmlns=″http://tempuri.org/″>  <AuthenticateInterfaceResult>    <Valid>boolean</Valid>   <Token>string<Token>    <ErrorMessage>string</ErrorMessage>  </AuthenticateInterfaceResult>  </AuthenticateInterfaceResponse> </soap12:Body> </soap12:Envelope>

The above message comprises a “Valid” value if the request from the EHMS130 was successfully processed; otherwise a “False” value is returned.If the request could not be successfully processed, the message alsocomprises an error message indicating the reason why the request wasdenied. If the request was successfully processed the communicationmanager 208 also sends a security token for the transmission to the EHMS130. It should be noted that the process above can be similarlyperformed for authentication of an EHMS 130 as well. Also, the abovemessages are only one example of an authentication request and responsethat can be sent by the EHMS 130 and portal 114. Various other messageswith different formats and content are applicable as well.

Once the EHMS 130 has obtained a security token, it can securely sendand receive data to/from the patient portal 114. For example, the EHMS130 is able to send a communication to the patient portal 114 forcreating an account for a patient within the portal 114 and to map thisaccount to the patient's account in the EHMS 130. In this example, thecommunication interface 140 generates a request/message with theportal-based patient ID if this ID has been provided by the patient. Thefollowing is one example of a request generated by the communicationinterface 140 for creating/linking a patient account in the portal:

<?xml version=″1.0″ encoding=″utf-8″?> <soap12:Envelopexmlns:xsi=http://www.w3.org/2001/XMLSchema-instancexmlns:xsd=″http://www.w3.org/2001/XMLSchema″xmlns:soap12=″http://www.w3.org/2003/05/soap-envelope″>  <soap12:Body>  <CreateAMRPatient xmlns=″http://tempuri.org/″>   <FacilityId>long</FacilityId>    <UserId>long</UserId>   <Token>string</Token>    <PatientData>    <AMRPatientId>long</AMRPatientId>    <Salutation>string</Salutation>     <FirstName>string</FirstName>    <MiddleName>string</MiddleName>     <LastName>string</LastName>    <Address1>string</Address1>     <Address2>string</Address2>    <Address3>string</Address3>     <City>string</City>    <State>string</State>     <Postal>string</Postal>    <CountryCode>string</CountryCode>     <HomePhone>string</HomePhone>    <MobilePhone>string</MobilePhone>     <WorkPhone>string</WorkPhone>    <Fax>string</Fax>     <EMail>string</EMail>     <DOB>dateTime</DOB>    <SSN>string</SSN>     <PreferredLanguageId>int</PreferredLanguageId>    <GenderId>int</GenderId>     <RaceId>int</RaceId>    <EthnicityId>int</EthnicityId>    <MaritalStatusId>int</MaritalStatusId>    <SmokingStatusId>int</SmokingStatusId>    </PatientData>  </CreateAMRPatient>  </soap12:Body> </soap12:Envelope>

When the portal 114 receives this message, the profile manager 202searches the user profiles 120 to identify a profile comprising theportal-based patient ID (e.g., “AMRPatientID”). FIG. 6 shows variousexamples of user profiles 120. In the example shown in FIG. 6, each row602, 604, 606 in the table 600 corresponds to a user profile. It shouldbe noted that in other embodiments, each patient profile 602, 604, 606is stored separate from one another. The table 600 comprises a pluralityof columns, each storing a different set of information. In thisexample, the table 600 comprises a first column 608 entitled “PatientID”; a second column 610 entitled “Record IDs”; a third column 612entitled “Login”; a fourth column 614 entitled “Password”, a fifthcolumn 616 entitled “Contact Information”; a sixth column 618 entitled“Prefs”; a seventh column 620 entitled “Billing Data”; and eighth column622 entitled “Facilities”, and a ninth column 624 entitled “Subscriber”.

The “Patient ID” column 608 comprises entries 626 uniquely identifyingthe patient associated with the user profile for the patient portal 114.The “Login” column 610 comprises entries 628 with the unique login oruser name assigned to the patient for interacting with the patientportal 114. The “Record IDs” column 612 comprises entries 630 uniquelyidentifying health-medical data 126 and records 128 associated with thepatient and maintained by the patient portal 114. These record IDs canalso point to a location where the data 126 and/or records 128 arestored. In one embodiment, the records 128 are the records received fromthe EHMS 130 (or the patient) and/or are records created by the patientportal 114 using the health-medical data 136 within an electronic record142 received from the EHMS 130 (or the patient). The patient portal 114is able to receive electronic records in various different formats,parse and extract their information, and generate its own electronicrecords 128 based on the extracted information. In this embodiment, therecord IDs are associated with and/or pointing to the patient portalgenerated records 128.

The “Password” column 614 comprises entries 632 with the unique passwordassigned to the patient for interacting with the patient portal. The“Contact Information” column 616 comprises entries 634 identifying thecontact information of the patient such as email addresses, homeaddress, phone numbers, and/or the like. The “Prefs” column 618comprises entries 636 that identify the patient preferences with respectto the patient portal. For example, the patient can configure how thedata presenter 204 presents information to the patient in the patientportal 114. In this example, the patient is able to select and configurethe types of information that are displayed to the patient in the portal114. Preferences can also include contact preferences and any otherpreferences that the patient is able to configure with respect to thepatient portal 114. The “Billing Data” column 620 comprises entries 638with various types of billing data associated with the patient (ifapplicable). Examples of billing data include subscription plan type,payment information, payment histories, and/or the like. The “Facility”column 622 comprises entries 640 with the facility ID (or a pointer tothe facility profile 122) of each facility associated with the patient.The “Subscriber” column 624 comprises entries 642 with the subscriber ID(or a pointer to the subscriber profile 121) of each EHMS associatedwith the patient. It should be noted that one or more of the columns andentries shown in FIG. 6 are optional, and additional information can beincluded within a user profile 120 as well.

Once the profile manager 202 identifies the user profile 120 comprisinga patient ID matching the ID sent in the request/message received fromthe EHMS 130, the manager 202 updates the profile 122 to link the userprofile 122 to the EHMS 130 and/or facility. For example, the profilemanager 202 updates the profile 122 to include the subscriber ID of theEHMS 130, the Facility ID of the facility, a pointer to the subscriberprofile 124 of the EHMS 130, a pointer to the facility profile 122 ofthe facility, and/or the like.

In some embodiments, the EHMS 130 may not have been provided theportal-based identifier for the patient. In this embodiment, the profilemanager 202 searches for a user profile 120 comprising data matching thepatient identifying information and demographics provided in thecommunication received from the EHMS 130. If a matching profile 120 isidentified, the portal 114 sends a communication to the EHMS 130comprising the portal-based ID of the patient and the EHMS 130 updatesits records accordingly. If a matching profile 120 cannot be identified,the portal manager 118 automatically registers the patient and generatesa user profile 120 for the patient comprising the patient identifyinginformation and demographics received from the EHMS 130. It should benoted that the portal 114 is not limited to automatically creating apresence for a patient based on an explicit request from the EHMS 130.For example, the portal 114 can also automatically create a presence forthe patient, a facility, and/or an EHMS within the portal 114 based onreceiving patient health-medical data from the EHMS 130 as discussed inthe co-pending U.S. patent application Ser. No. ______, entitled“Automatic Generation Of Patient Presence For Patient Portals” filed on______, which is hereby incorporated by reference in its entirety.

The portal 114 sends a communication to the EHMS 130 comprising theportal-based ID of the patient, and the EHMS 130 updates its recordsaccordingly. The portal 114 can also send a welcome letter to the EHMS130. The appropriate provider associated with the EHMS 130 then providesthis welcome letter to the patient. In one embodiment, the welcomeletter at least provides a portal login for the patient, a portalpassword for the patient, and/or a uniform resource locator (URL) forthe patient portal 114. The following is one example of the responsesent to the EHMS 130 from the portal 114 based on a request from theEHMS 130 for creating/linking a patient account in the portal:

<?xml version=″1.0″ encoding=″utf-8″?>  <soap12:Envelopexmlns:xsi=″http//www.w3.org/2001/XMLSchema-instance″ xmls:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:soap12=″http://www.w3.org/2003/05/soap-envelope″>   <soap12:Body>   <CreateAMRPatientResponse xmlns=″http://tempuri.org/″>    <CreateAMRPatientResult>      <Valid>boolean</Valid>     <ErrorMessage>string</ErrorMessage>     <AMRPatientId>long</AMRPatientId>     <WelcomeLetter>string</WelcomeLetter>     </CreateAMRPatientResult>   </CreateAMRPatientResponse>   </soap12:Body>  </soap12:Envelope>

The above message/response comprises a “Valid” value if the request fromthe EHMS 130 was successfully processed; otherwise a “False” value isreturned. If the request could not be successfully processed, themessage also comprises an error message indicating the reason why therequest was denied. If the request was successfully processed theresponse comprises the portal-based patient ID and a welcome letter (ifapplicable). It should be noted that above messages are only one exampleof a patient account creation/linking request and response that can besent by the EHMS 130 and portal 114. Various other messages withdifferent formats and content are applicable as well.

In addition to creating/linking a patient account in the portal 114, theEHMS 130 can also request to create and/or link a provider account inthe portal 114. Examples of providers includes (but are not limited to)doctors, nurse practitioners, physicians assistants, nurses, and/or thelike. This communication is similar to the one shown above and comprisesthe identifier of the facility associated with the communication theuserID (login) of the facility for the portal 114; the security tokenreturned by the authentication process discussed above; and a datastructure comprising provider data including the identifier of theprovider in the EHMS system 130, the title of the provider, the firstname of the provider, the middle name of the provider, the last name ofthe provider, the DEA number of the provider, the license number of theprovider, the provider's home phone, the patient's email address, and/orthe like. The portal 114 processes this communication and stores theprovider data as health-medical data 126, which can be stored in one ormore records 128. Also, the user profiles 120, facility profiles 122,and subscriber profiles 124 can be updated to include the receivedprovider data or at least a pointer to the provider data (or record 128comprising the data).

Another type of communication that is sent from the EHMS 130 to theportal 114 is a patient health-related record/data communication, whichcomprises patient health-related information. In one embodiment, thedata 136 from an electronic record 142 is transmitted to the patientportal 114 according to one or more standards; however this is notrequired. In this embodiment, structured and/or unstructured data(including attachments in binary form) comprising patient identifyinginformation, patient health-related information, patient medical-relatedinformation, and/or the like is sent to the patient portal 114. Forexample, an electronic record 142 can be transmitted from the EHMS 130or the system 108 of an individual patient as structured and/orunstructured data, a Continuation of Care Record (CCR), a Continuity ofCare Document (CCD) or one of its equivalents/permutations, anunstructured clinical document architecture (CDA) record, and/or thelike. In one embodiment, an integrated facility/EHMS sends structureddata while a non-integrated facility/EMRS sends unstructured (orsemi-structured) data); however, this is not required and each can sentany type of data to the patient portal 114. It should be noted thatembodiments of the present disclosure are not limited to such examples,and electronic records 142 or their data can be transmitted to thepatient portal 114 in any format.

CCRs and CCDs are both data sets conforming to specific health recordstandard specifications. A CCR comprises a summary of a patient's healthstatus including medications, allergies, problems, insuranceinformation, care plans, and/or the like. There are six sections of aCCR that have mandated core elements. These sections include a header,patient identifying information, patient financial and insuranceinformation, health status of the patient, care documentation, and careplan recommendation. A CCD document comprises a dataset that conforms toan XML-based markup standard that specifies the semantics, encoding, andstructure of a patient summary clinical document. A CCD comprisesinformation such as the “Common MU Data Set”, where “MU” stands forMeaningful Use, This data set comprises Patient name, sex, date ofbirth, race, ethnicity, preferred language, smoking status, problems,medications, medication allergies, laboratory tests, laboratoryvalues/results, vital signs, care plan fields including goals andinstructions, procedures and care team members. Other information suchas referral reasons, discharge instructions, encounter diagnoses, andimmunizations can also be included within a CCD.

A CCD document is a human and machine-readable document comprisingstructured and, optionally, unstructured content. A CCD is generatedaccording to the Clinical Document Architecture (CDA), which is an HL7authored health care documentation standard. The CDA is a base standardthat provides common architecture, coding, semantic framework, andmarkup language for the creation of electronic clinical documents. FIG.23 shows one example of the structure and format of a CCD 2302. In thisexample, the CCD comprises a header 2304, a body 2306, and one or moresections 2308. The one or more sections 2308 comprise a narrative block2310, and one or more entries 2312.

The header 2304 sets the context for the CCD as a whole. The header23023 allows management of the CCD and allows it to be exchanged acrossand within different institutions. The body 2306 comprises the clinicalreport and can comprise structured content that is organized into one ormore sections 2308. The body 2306 can also comprise an unstructured setof data as well. Each section 2308 comprises a narrative block 2310 and,optionally, one or more coded entries such as medications, allergies,immunizations, vital signs, and problems. Narrative blocks 2310 providehuman-readability of a CCD. The narrative block within a documentsection 2308 represents the content to be rendered for viewing. Entries2312 provide machine-readability to the CCD. Entries 2312 within adocument section 2308 represent structured content for further computerprocessing. The EHMS 130 is able to generate a CCD using one or moreCDA-based templates. The EHMS 130 can select from one or more headertemplates, a body templates, and section templates, narrative blocktemplates, and entry templates. Each of these templates is designed tosatisfy a specific information exchange scenario and defines the CDAstructures to be used to document the applicable clinical information.

In one embodiment, the EHMS 130 is configured to automatically transmita patient's electronic records 142 once they are created or after one ormore predefined conditions have occurred. For example, after a doctorhas evaluated the patient and has reviewed the information entered intothe patient's record 142 at the EHMS 132, the doctor selects an optionto save the record 142. The EHMS 132 detects that the record has beensaved and automatically sends the data 136 within the record 142 to thepatient portal 114. It should be noted that other conditions areapplicable as well such as the completion and signing of a clinicalnote, the signing of lab results, temporal conditions, and/or the like.Alternatively, a health care professional can manually instruct the EHMS130 to transmit a patient's electronic data 136 and/or records 142 tothe patient portal 114.

When the EHMS 130 detects that an automatic sending condition hasoccurred or receives an instruction from an EHMS user system 106, theEHMS 130 transmits one or more electronic records 142 to the patientportal 114. The record/data can be packaged as a CCR, CCD, unstructuredCDA, and/or the like; however this is not required. The following is oneexample of a communication comprising patient clinical data that is sentfrom the EHMS 130 to the portal 114:

<?xml version=″1.0″ encoding=″utf-8″?>  <soap12:Envelopexmlns:xsi=″http//www.w3.org/2001/XMLSchema-instance″ xmls:xsd=″http://www.w3.org/2001/XMLSchema″ xmlns:soap12=″http://www.w3.org/2003/05/soap-envelope″>   <soap12:Body>   <CCDPost xmlns=″http://tempuri.org/″>    <FacilityId>long</FacilityId>     <UserId>long</UserId>    <Token>string<Token>     <CCDData>     <AMRPatientId>long</AMRPatientId>     <Document>base64Binary</Document>     </CCDData>    </CCDPost>  </soap12:Body>  </soap12:Envelope>

In this example, the communication generated by the EHMS 130 comprisesthe ID of the facility associated with the communication; the userID(login) of the facility for the portal 114; the security token returnedby the authentication process discussed above; and a data structurecomprising the portal-based patient identifier of the patient associatedwith the communication, and a CCD document converted to a byte string.It should be noted that a similar communication can also be sent by theEHMS 130 comprising patient visit-based data such as the visitidentifier; the provider identifier; visit reason; insuranceinformation; a problem list comprising a SNOMED Codes, Code Types forthe SNOMED Codes, condition information, the data the condition wasidentified, condition status, notes on the condition; medicationinformation; allergy information; vital signs; family historyinformation; social history information; medical history information;surgical history information; medical procedure information;immunization information; plan of care information; and/or the like.

Lab result data can also be included within a communication similar tothe one shown above. This communication comprises, for example, theuserID (login) of the facility for the portal 114; the security tokenreturned by the authentication process discussed above; and a datastructure comprising an identifier of the lab visit, the portal-basedpatient identifier of the patient associated with the communication, theidentifier of the provider who ordered the lab, the name of the lab, thedate/time the lab was ordered, the date/time the sample was collected,the requisition number, the specimen code, the source of the specimen,the date/time the report was ordered, the date/time the report wasreviewed, the name of the reviewed, the component tested, the result,the reference range, the measurement units, an indication of the resultswere normal/abnormal, results status, and/or the like.

In addition, the EHMS 130 is able to send documents such as clinical andmedical notes to the EHMS 130 using a communication similar to the oneshown above. In one embodiment, the document is sent as an image;however this is not required. In this embodiment, the communicationcomprises the ID of the facility associated with the communication; theuserID (login) of the facility for the portal 114; the security tokenreturned by the authentication process discussed above; and a datastructure comprising data associated with the document such as anidentifier associated with the visit, the portal-based patientidentifier associated with the patient, an identifier or name of thedocument in the sending system, a description of the document (ordocument name), the date/time the document was created, the documentimage format (e.g., PDF, TIF, etc.), the document image, any notes onthe document, and/or the like.

Once received by the portal 114, the communication manager 208 processesthe communication from the EHMS 130 and stores the health-related dataand/or record included within the communication. In one embodiment, theportal manager 118 generates one or more portal records 128 comprisingthe health-medical data 126 received in the communication. This allowthe patient portal 114 to receive health-related records and data in anyformat and process the data independent of the EHMS 130 that sends therecord/data. The profile manager 202 of the portal 114 updates the userprofile 120 for the patient identified in the communication. Forexample, the profile manager 202 updates the user profile 120 to includea pointer to the data 126 and/or record 128 (or an identifier associatedtherewith). Once the portal 114 has processed the communication receivedfrom the EHMS 130, it sends a response back to the EHMS similar to theresponses discussed above. It should be noted that above message is onlyone example of an health-related data communication and response thatcan be sent by the EHMS 130 and portal 114. Various other messages withdifferent formats and content are applicable as well.

In addition to sending the patient portal 114 various types ofhealth-related information, the EHMS 130 can also check for and respondto messages waiting to be processed at the patient portal 114. In oneembodiment, the EHMS 130 checks for messages at the portal 114 atscheduled intervals; however, the portal 114 can also send anotification to the EHMS 130 indicating that a message is waiting to beprocessed. In this embodiment, the EHMS 130 sends a communicationsimilar to those discussed above along with an indication that it ischecking for messages. The portal 114 receives this communication andresponds back with a response similar to those discussed above. In oneexample, the response sent by the portal 114 comprises an indicationwhether the request from the EHMS 130 was successfully processed; anerror message if the request was not successfully processed; and a datastructure comprising an identifier of each waiting message, theportal-based patient identifier of the patient associated with themessage, the message type (e.g., appointment request, medication refill,billing message, general inquiry, referral message, and/or the like), anoptional identification of the provider to which the message isaddressed, text request from the patient, preferred time of day for anappointment (if applicable), preferred time for appointment (ifapplicable), preferred day(s) for appointment (if applicable), patiententered text as to why they need an appointment (if applicable), visiturgency (if applicable), name of medication (if applicable), name ofpharmacy (if applicable), and/or the like. The EHMS 130 responds to thismessage by sending a message similar to those above along with messageidentifier, the identifier of the provider who is responding, theresponse to the request, responses to each of the request within themessage, and any attachments (e.g., prescriptions).

In some embodiments, the communications sent between the EHMS 130 andthe portal 114 are transmitted via one or more secured mechanisms;however this is not required. For example, the EHMS 130 and the patientportal 114 are each associated with a security key pair that is used toencrypt/decrypt information being transmitted there between. In oneembodiment, the messaging module 138 and/or the communication interface140 encrypts the communications sent from the EHMS 130 with the publickey of the patient portal 114, and also signs the communication with theprivate key of the EHMS 130. The communication interface 140 then sendsthe encrypted communication to the patient portal 114 via the securecommunication link. It should be noted that the message and/or theirdata are not required to be encrypted prior to being sent to the patientportal 114 since the secure communication link provides an encryptedpipe such that the messages are securely encapsulated when beingtransmitted to the patient portal 114.

In addition, the EHMS 130 and the patient portal 114 can utilize one ormore information exchange technologies such as DIRECT messaging(DIRECTProject.org), which provide secure messaging between sender andrecipient parties, to transmit information between each other. Forexample, DIRECT messaging can be utilized to send secure emails, securepoint-to-point messages (utilizing, for example, the Cross EnterpriseReliable Interchange (XDR) interface), and/or the like between the EHMS130 and patient portal 114. Secure email utilizes the S/MIME standardfor exchanging encrypted emails. With DIRECT messaging, certificates ofthe sending/receiving parties can be automatically discovered andretrieved across various networks such as the Internet.

In an embodiment where DIRECT messaging is to be used, the EHMS 130 andthe patient portal 114 are each associated with a security key pair thatis used to encrypt information being transmitted there between. The EHMS130 and patient portal can send secured messages directly to each otherand/or through one or more third-party servers. In an embodiment, wherethird-party servers are utilized, the EHMS 130 and patient portal 114are both part of the same or different secured/trust network such asthose provided by Health care Information Service Providers (HISPs). Inthis embodiment, the EHMS 130 generates an electronic communication(e.g., email message) comprising an electronic record 142 or its dataaddressed to a DIRECT messaging address (e.g., DIRECT-messaging-basedemail address) of the patient portal 114. In one embodiment, theelectronic record 142 or its data is packaged in a CCR, CCD orunstructured CDA form; however this is not required.

When utilizing DIRECT messaging, the messaging module 138 of EHMS 130sends the electronic communication to the patient portal 114 through atleast one source trust server. This trust server receives the electroniccommunication and identifies the destination address, which is themessaging address of the patient portal 114. The trust server identifiesthe security certificate of the patient portal 114, generates anS/MIME-based message, and signs the message with the private key of theEHMS 130. The trust server further encrypts the message with thecertificate (public key) of the patient portal 114 and sends thisencrypted message to the patient portal 114.

The patient portal 114 can then receive the electronic communication inits encrypted form and perform decrypting operations itself.Alternatively, a destination trust server can intercept this encryptedcommunication and perform, for example, an S/MIME decryption processusing the private key of the patient portal. After the communication andits content are decrypted, this trust server verifies the communicationusing a certificate (public key) of the EHMS 130. Once verified, thedestination trust server sends the decrypted communication with itscontent to the patient portal 114 using its DIRECT messaging address.The patient portal 114 receives the communication from the EHMS 130along with its data (e.g., electronic records/data) in an unencryptedform.

In another embodiment, the third-party servers are not required. Forexample, the EHMS 130 and the patient portal can securely communicationdirectly with each other. In this embodiment, the messaging module 138of the EHMS 130 implements or is communicatively coupled to the patientportal communication interface 140. In one embodiment, the communicationinterface 140 utilizes standard web services protocols that transfermessages in a markup language format. These messages can be transmittedover HTTP or another protocol. The communication interface 140, in oneembodiment, utilizes one or more security technologies such as SSL(Security Socket Layer) over HTTPS to securely communicate and encryptthe data exchange and communications between the EHMS 130 and thepatient portal 114. The communication interface 140 utilizes one or moreinformation exchange technologies such as DIRECT messaging to transmitinformation to the patient portal 114.

In another embodiment, a secure communication link is not establishedbetween the EHMS 130 and patient portal 114. In this embodiment, themessaging module 138 of the EHMS 130 securely encrypts the electronicrecords 142 prior to transmitting them to the patient portal 114. Inthis embodiment, the messaging module 138 generates a message/packetcomprising the encrypted data and sends the message to a messagingaddress (e.g., email address) of the patient portal. In anotherembodiment, the EHMS 130 transmits data to the patient portal 114 in anunsecured form over an unsecured link. It should be noted thatembodiments of the present disclosure are not limited to the aboveexamples directed to securely transmitting electronic record data to thepatient portal 114. Other mechanisms for securely transmittingelectronic record data to the patient portal 114 are applicable as well.

It should also be noted that the above discussion is applicable tosending electronic records/data or images thereof from a user/patientsystem 108 via a messaging module 152 such as an application, plug-in,web browser, and/or the like residing on a user/patient system 108. Theuser/patient system 108 can also comprise one or more interfaces 154such as the patient portal communication interface discussed above forcommunicating with the patient portal 114. In addition, a patient isable to utilize a device such as a wireless communication device, aportable electronic device, a desktop computer, and/or the like tocapture an image of an object comprising his/her health relatedinformation. For example, the patient can have health or medical relateddata in paper form such as lab results, doctors' records, prescriptions,radiology images, radiology reports, physical therapy treatment plans,hand written health or medical related information, and/or the like.

The patient is able to utilize a camera, scanner, and/or the like tocapture in an image of these items, and transmit the image to thepatient portal 114 for processing. Alternatively, the patient's device108 can also process the image and send health-related data items to thepatient portal. The patient transmits his/her health or medical relatedinformation to the patient portal via one via one or more communicationmechanisms such as via an email message, a SMS message, a MMS message, aDIRECT message, by uploading to the portal 114 through a web browser,transmission through a dedicate portal application 114 residing on theuser's system 108, and/or the like. A more detailed discussion on onemore examples of a patient transmitting health-related data to thepatient portal 114 is given in the co-pending U.S. patent applicationSer. No. ______, entitled “User-Based Remote Capturing Of Health AndMedical Related Data” filed on ______, which is incorporated byreference in its entirety.

Also, embodiments of the present disclosure are not limited to afacility, EHMS, and/or a patient that has been previously registeredwith the patient portal 114. For example, an unregistered entity is ableto utilize a browser to upload structured, semi-structured, and/orunstructured data (including attachments in binary form) to the patientportal. These unregistered entities are also able to send an emailmessage, SMS message, MMS message, instant message, DIRECT message,and/or the like to a messaging address of the patient portal comprisinghealth-related data within the subject and body sections of the message(and/or attached thereto). The patient portal 114 receives thecommunications from unregistered entities and processes them similar tothat discussed above including creating (automatically or based on arequest from the sending entity) a presence for the unregisteredentities associated with the communication in the portal 114).Therefore, the patient portal 114 is able to receive communicationscomprising health-related data/requests from registered and unregisteredEHMSs, facilities, and patients.

When the patient portal 114 receives a communication comprisinghealth-related information, the communication manager 208 extracts thedata/record(s) included within (or attached to) the communication. Thedata/record(s) is stored as health-medical data 126 and can bemaintained in one or more records 128. The portal manager 118 canmaintain the records/data in the form they were received and/or generateone or more portal-based records 128 comprising the information therein.It should be noted that if the received records/data comprisesstructured data, the portal manager 118 can maintain the structure andformatting properties of the data/records.

In one embodiment, the communication manager 208 identifies and recordsthe source of the health-medical data 126 (and records 128 when the arethe records received from a source and not generated by the portalmanager 118). Stated differently, the communication manager 208identifies and records whether the health-medical data 126 was receivedfrom an integrated partner, a non-integrated entity, or a patient. Forexample, if the health-medical data 126 was received from a patient, thecommunication manager 208 assigns a source type of “patient entered” tothe health-medical data 126. If the health-medical data 126 was receivedfrom an integrated partner, the communication manager 208 assigns asource type of “integrated partner” to the health-medical data 126. Theidentifier and/or the name of the subscriber/facility that sent thehealth-medical data 126 can also be assigned to the record/data as thesource type as well. If the health-medical data 126 was received from anon-integrated entity, the communication manager 208 assigns a sourcetype of “non-integrated” to the health-medical data 126. The identifierand/or the name of the non-integrated subscriber/facility that sent thehealth-medical data 126 can also be assigned to the health-medical data126 as the source type as well. The source type can be added as anannotation to the stored health-medical data 126, added as a field inthe health-medical data 126, and/or the like. If the portal manager 118generates a record 128 from the health-medical data 126 extracted from acommunication, the assigned source type is included within this record128.

It should be noted that instead of (or in addition to) a source typebeing assigned to received health-medical data 126, the communicationmanager 208 can store the health-medical data 126 (and records 128) in asection of memory/storage that is allocated for a given source type. Forexample, a first portion of storage can be allocated for health-medicaldata 126 received from integrated partners. A second portion of storagecan be allocated for health-medical data 126 received fromnon-integrated partners. A third portion of storage can be allocated forhealth-medical data 126 received from patients. Therefore, the portalmanager 118 is able to determine the source type of storedhealth-medical data 126 based on which portion of storage they aremaintained in.

Patient Interaction with the Patient Portal

As discussed above, the patient portal 114 is a health care-relatedwebsite and/or online application or service that allows patients tosecurely manage and view their health information created by one or morehealth care providers (e.g., physicians and hospitals) and/or providedby the patient. A patient is able to log into the patient portal from aweb browser and/or an application residing on his/her user system 108.After the patient enters his/her login credentials and has beenauthenticated by the portal manager 118, the data presenter 204 presentsa personalized portion 702 of the interactive environment 116 to thepatient, as shown in FIG. 7.

The personalized portion 702 of the interactive environment 116 shown inFIG. 7 comprises a first section 704 that identifies the patient. Thissection 704 comprises the patient's name, picture, and/or the like. Thissection 704 also comprises various portal management options such as anaccount settings option 706, an option 708 to view the patient's healthrecord, an option 710 to view, download, and/or transmit the patient'shealth-related records, and an option 712 (if applicable) to upgrade toa premium paid service or downgrade from the premium service to a freeservice. The account settings option 706 allows the patient to view/editvarious account setting such as passwords, address information, phoneinformation, email addresses, payment information, and/or the like. Thehealth record option 708 allows the patient to view all of his/herhealth-related information. The view, download, and/or transmit option710 allows the patient to view, download, customize, and/or transmitindividual health-related records entered by the patient, integratedpartners, and non-integrated entities. This option 712 is discussed ingreater detail below.

The personalized portion 702 of the interactive environment 116 furthercomprises a second section 714 that displays various premium servicesoffered to the patient. Examples of premium services include (but arenot limited to) a drug information center, a health information library,an In Case of Emergency (ICE) program, a pharmacy locator, a medical IDbracelet ordering option, a medical ID card, an online blood lab option,prescription discount card, and/or the like. It should be noted thatservices and options that are identified as premium services/options insome embodiments can be free services in other embodiments, and viceversa.

FIG. 7 further shows a third section 716 of the interactive environment116 comprising one or more selectable options that allow the patient toview and interact with various different types of health-related data.Examples of selectable options include (but are not limited to) a homeoption 718, a clinical summary option 720, a messages option 722, anappointments option 724, a medications option 726, a referrals option728, a premium services option 730, a marketplace option 732, a managedoctors option 734, an emergency contacts option 736, a share my recordsoption 738, a medical portfolio option 740, and a digital file cabinetoption 742. One or more of these options can be provided to the patientas a paid-for premium service. In one embodiment, when the patient viewshealth-medical data 126 or records 128 made available by a facility orprovider, the portal manager 118 records this interaction in the logsection of the user profile 120. The log data can identify thedata/record interacted with, the interaction performed by the user, thedate and/or time of interact, an identification of the facility and/orprovider associated with the data/record, and/or the like. This log datacan also be maintained within a facility profile 122, subscriber profile124, a profile for the provider, and/or the like.

When the patient selects the home option 718, a home area 744 of theinteractive environment 116 is populated with various types ofinformation and options. In particular, the home option 718 provides apatient customizable view of his/her health-related data. For example,the patient is able to select one or more widgets from a list of widgetsto be displayed in his/her home section of the interactive environment116. The patient is also able to place each of these widgets at adesired location within the home section of the interactive environment116. The portal manager 116 records the patient's widget selections andtheir positioning information within the preferences section of thepatient's user profile 120. It should be noted that default widgets canalso be displayed and positioned at default locations. Also, patientselected widgets can be placed at default locations as well.

In one embodiment, each widget is associated with a different type ofhealth-related information. For example, a first widget 746 comprisesprovider visit data, a second widget 748 comprises family history data,a third widget 750 comprises medication data, a fourth widget 752comprises past medical history data, a fifth widget 754 comprisespatient health-medical problems, and a sixth widget 756 comprisesimmunization data. Other examples of widgets include (but are notlimited to) provider appointment data, social history data, lab testdata, provider statement/billing data, vitals data, insurance data,allergy data, provider-based documents, plan of care data, medicalprocedure data, and/or the like.

The data presenter 204 populates each displayed widget based on thehealth-medical data 126 extracted from the received communicationsassociated with the patient and/or associated records 128. For example,the data presenter 204 searches the health-medical data 126, records,128, and/or profiles 120, 122, 124 to identify the appropriate data foreach widget. In this embodiment, the portal manager 114 associates thehealth-medical data 126 and records 128 with a given data type suchvisits, family history, medications, etc. The data types can be alreadyassociated with the health-medical data and records in the communicationreceived from an EHMS, facility, and/or patient. The portal manager 114can also be trained to analyze the health-medical data 126 (and records128) and recognize the data type from this analysis. The data presenter204 identifies the health-medical data 126 (and records) comprising adata type corresponding to the data type of each widget, and populatesthe various fields within each widget with the appropriatehealth-medical data 126 (or records 128). Also, the patient is able toselect a given entry within a widget to view additional details of thatparticular entry. Also, some entries such as lab result entries can beselected to have an image, a document (e.g., lab result document),and/or the like displayed to the patient.

In one embodiment, the patient selects source type 758 (or aprovider/facility name) so that the data displayed in a widget is dataprovided by an integrated partner, a non-integrated partner, or enteredby the patient. In the example shown in FIG. 7, the patient has selectedthe source type of “Patient Entered”. Therefore, when the data presenter204 is searching the health-medical data 126, records, 128, and/orprofiles 120, 122, 124 to identify the appropriate data for each widgetthe presenter 204 identifies data with a source type identifier of“Patient Entered”. The source type option 758 allows the patient to viewand identify which data was provided by a given source type. Each widgetcan comprise a field that identifies the source type of each entrywithin the widget. Also, different widgets can be displayed based on thesource type selected by a patient. A visit date option 760 can also beprovided to the patient that allows the patient to select a providervisit date. The data presenter 204 searches the health-medical data 126,records, 128, and/or profiles 120, 122, 124 to identify data that isassociated with the specified visit date. The data presenter 205 thenpopulates the widgets with the identified data.

Each widget can be associated with one or more widget options such as anadd option 762, a share option 764, and a hide option 766. The addoption 762 allows the patient to add one or more entries into thewidget. For example, if the patient selects an add option for themedications widget 750, a form is presented to the patient that allowshim/her to add medication related information such as medication name,when the patient first starting taking the medication or stopped takingit, the number of refills left, etc. The share option 764 allows thepatient to indicate whether the information within or associated thewidget can be shared with someone or is to be kept hidden/confidential(i.e., not shared or displayed to parties other than the patient). Thepatient is able to select specific entries in the widget and indicate ifthese entries are sharable or confidential, or can have thesharable/confidential property be applied to all entries within thewidget. The portal manager 118 updates the records 128 comprising thehealth-medical data 126 within each widget or annotates thehealth-medical data 126 with an identifier or flag indicating whetherthe data 126 has been marked as sharable or hidden. If the patient hasnot specified a sharable/confidential property for data 126, the portalmanager 118 can apply a default property to the data 126. Also, eachentry within a widget can be associated with a status field indicatingwhether the entry (or its associated data/record) is sharable or to bekept hidden/confidential.

In another embodiment, the share option 764 allows the patient to selectone or more parties to share the information (either all entries or onlyentries marked as sharable) with. For example, the patient can providerecipient details such as mailing address, messaging address, faxnumber, etc. of a recipient. Alternatively, the patient selects arecipient from a list of recipients such as a provider list. The portal114 then transmits the selected data to the recipient using one or moretransmission mechanisms such as those discussed above. Alternatively,the recipient can be notified that a message is waiting to be downloadedby the recipient. The hide option 766 allows the patient to hide a givenwidget from view. It should be noted that one or more of the widgetsoptions can be source type dependent. For example, the add option 762,in one embodiment, is not provided to the patient for one or morewidgets that are displaying data with an “integrated partner” sourcetype; however, this is not required.

In addition to the above, the home are 744 of the interactiveenvironment 116 also provides the patient with a send message option768, an appointments option 770, a refill medication option 772, and arequest referral option 774. The send message option 774 allows thepatient to send one or more messages to a given provider. For example, aform is presented to the patient that allows the patient to select orinput a facility, a given provider, a message subject, a messagepriority, and/or the like. The patient can also enter a specific messageinto the form. Once the patient has created the message the portal 114securely sends the message to the recipient or notifies the recipientthat a message is waiting, as discussed above. The appointments option770 allows the patient to request an appointment for a given provider.The refill medication option 772 allows the patient to request a refillfor one or more medications. The referral request option 774 allows thepatient to request a referral from his/her physician. It should be notedthat the home area 744 of the interactive environment 116 is not limitedto the examples discussed above.

FIG. 8 shows one example of a clinical summary section 802 of theinteractive environment 116. This section 802 is presented to thepatient within the interactive environment 116 when the patientselections the clinical summary option 720. However, this section or anyother section can be set as the patient's default section that isdisplayed to the patient when he/she logs into the portal 114. Theclinical summary section 802 comprises a plurality of viewing optionssuch as a summary option 804, a lab tests option 806, a histories option808, an allergies option 810, a visits option 812, an immunizationsoption 814, a problems option 816, a vitals option 818, and a documentsoption 820.

The summary option 804 presents a chart summary 822 to the patient. Thechart summary 822 is populated by the data presenter 204 with variousdemographic 824 and personal information 826 associated with thepatient. The demographic and personal data 824, 826 is obtained by thedata presenter 204 from the user profile 120, health-medical data 126,and/or records 128 associated with the patient. The clinical summarysection 822 optionally displays one or more widgets 828, 830 similar tothose discussed above with FIG. 7 along with one or more of the widgetoptions. The patient is also presented with a source type option 832 anda visit date option 834 similar to those discussed above with respect toFIG. 7.

When the patient selects the lab tests option 806, the data presenter204 updates the clinical summary section 802 to display lab testsresults records/data to the patient. Information such as lab name,source, provider, order date, collection date, report date, review date,and results are displayed to the patient. The patient is able to selectthe results portion to view the actual lab results. The patient is alsopresented with a source type option and a visit date option similar tothose discussed above with respect to FIG. 7. The patient selects agiven source type and/or a visit date to view lab results recordsprovided by the selected source and/or for a given visit date. Thepatient is also presented with one or more data options such as an addoption and a share option similar to the widgets options discussedabove. The add option allows the patient to add additional lab resultsto his/her health-related data 126. The share option allows the patientto associate a sharable/confidential property to all lab results entriesor specific entries, as discussed above.

The histories option 808 presents history-related information such associal history information, family history information, and past medicalhistory information to the patient. Social history information such asdescription, qualifier, code value, start date, end date, notes, anddetails are displayed to the patient. The patient is able to select thedetails area to view additional details for the given entry. Familyhistory information such as relationship, condition description, notes,and details are displayed to the patient. The patient is able to selectthe details area to view the additional details for the given entry.Past medical history information such as date, diagnosis/disease, notes,and details are displayed to the patient. The patient is able to selectthe details area to view the additional details for the given entry.

The patient is also presented with a source type option and a visit dateoption similar to those discussed above with respect to FIG. 7. Thepatient selects a given source type and/or a visit date to see historyrecords provided by the selected source type and/or for a given visitdate. The patient is also presented with one or more data options suchas an add option and a share option similar to the widgets optionsdiscussed above. The add option allows the patient to add additionalhistory data to his/her health-related data 126. The share option allowsthe patient to associate a sharable/hidden property to all history dataentries or specific entries, as discussed above. The share option canalso allow the patient the designate one or more parties to share thedata with.

The allergies option 810 displays various allergy information/records tothe patient in the clinical summary section 802. Allergy informationsuch as effective date, allergen type, allergen, reaction, notes,status, and details are displayed to the patient. The patient is able toselect the details area to view the additional details for theassociated entry. The patient is also presented with a source typeoption and a visit date option similar to those discussed above withrespect to FIG. 7. The patient selects a given source type and/or avisit date to see allergy information/records provided by the selectedsource and/or for a given visit date. The patient is also presented withone or more data options such as an add option and a share optionsimilar to the widgets options discussed above. The add option allowsthe patient to add additional allergy information/records to his/herhealth-related data 126. The share option allows the patient toassociate a sharable/confidential property to all allegery entries orspecific entries, as discussed above. The share option can also allowthe patient the designate one or more parties to share the data with.

The visits option 812 displays various provider/facility visitinformation or records to the patient in the clinical summary section802. Visit information such as date of visit, visit reason, provider,location, and details are displayed to the patient. The patient is ableto select the details area to view the additional details for theassociated entry. The patient is also presented with a source typeoption and a visit date option similar to those discussed above withrespect to FIG. 7. The patient selects a given source type and/or avisit date to see visit information/records provided by the selectedsource and/or for a given visit date. The patient is also presented withone or more data options such as an add option and a share optionsimilar to the widgets options discussed above. The add option allowsthe patient to add visit information/records to his/her health-relateddata 126. The share option allows the patient to associate asharable/confidential property to all visit entries or specific entries,as discussed above. The share option can also allow the patient thedesignate one or more parties to share the data with.

The immunizations option 814 displays various immunizationinformation/records to the patient in the clinical summary section 802.Immunization information such as immunization date, vaccineadministered, and details are displayed to the patient. The patient isable to select the details area to view the additional details for theassociated entry. The patient is also presented with a source typeoption and a visit date option similar to those discussed above withrespect to FIG. 7. The patient selects a given source type and/or avisit date to see immunization information/records provided by theselected source and/or for a given visit date. The patient is alsopresented with one or more data options such as an add option and ashare option similar to the widgets options discussed above. The addoption allows the patient to add immunization information/records tohis/her health-related data 126. The share option allows the patient toassociate a sharable/confidential property to all immunization entriesor specific entries, as discussed above. The share option can also allowthe patient the designate one or more parties to share the data with.

The problems option 816 displays various problems information/records tothe patient in the clinical summary section 802. Problem informationsuch as onset date, description, notes, status, and details aredisplayed to the patient. The patient is able to select the details areato view the additional details for the associated entry. The patient isalso presented with a source type option and a visit date option similarto those discussed above with respect to FIG. 7. The patient selects agiven source type and/or a visit date to see problemsinformation/records provided by the selected source and/or for a givenvisit date. The patient is also presented with one or more data optionssuch as an add option and a share option similar to the widgets optionsdiscussed above. The add option allows the patient to add problemsinformation/records to his/her health-related data 126. The share optionallows the patient to associate a sharable/confidential property to allproblem entries or specific entries, as discussed above. The shareoption can also allow the patient the designate one or more parties toshare the data with.

The vitals option 818 displays various problems information/records tothe patient in the clinical summary section 802. Vitals-basedinformation such as observation date, blood pressure, weight, height,BMI, and details are displayed to the patient. The patient is able toselect the details area to view the additional details for theassociated entry. The patient is also presented with a source typeoption and a visit date option similar to those discussed above withrespect to FIG. 7. The patient selects a given source type and/or avisit date to see vitals-based information/records provided by theselected source and/or for a given visit date. The patient is alsopresented with one or more data options such as an add option and ashare option similar to the widgets options discussed above. The addoption allows the patient to add vitals-based information/recordsresults to his/her health-related data 126. The share option allows thepatient to associate a sharable/confidential property to all lab resultsentries or specific entries, as discussed above.

The documents option 820 displays various documents information/recordsto the patient in the clinical summary section 802. Documentsinformation such as date, document description, and notes details aredisplayed to the patient. The patient is able to select the entry toview the actual document associated therewith. The patient is alsopresented with a source type option and a visit date option similar tothose discussed above with respect to FIG. 7. The patient selects agiven source type and/or a visit date to see documentinformation/records provided by the selected source and/or for a givenvisit date. The patient is also presented with one or more data optionssuch as an add option and a share option similar to the widgets optionsdiscussed above. The add option allows the patient to add documentinformation/records to his/her health-related data 126. The share optionallows the patient to associate a sharable/confidential property to alldocument entries or specific entries, as discussed above. The shareoption can also allow the patient the designate one or more parties toshare the data with.

When the portal manager 118 detects that the patient has selected themessages option 722 of the home area 744, the data presenter 204displays a messaging section 902 to the patient in the interactiveenvironment 116 as shown in FIG. 9. The messaging section 902 displaysvarious messages sent to the patient from providers, facilities, and/orthe like. The messaging section 902 also allows the patient to createand manage messages. In one embodiment, the messaging section 902comprises a compose message option 904 that allows the patient to createone or more messages to be sent to a provider, facility, and/or thelike.

The messaging section 902 also displays one or more selectable optionssuch as an inbox option 906, a sent items option 908, a deleted option910, an appointments option 912, a medication refill option 914, and areferral request option 916. FIG. 9 shows one example of the messagingsection 902 after the patient has selected the inbox option 906. Whenthe inbox option 906 is selected, a list of received messages 918 isdisplayed to the patient. Each entry in this list 918 identifies thesender 920, the recipient 922, the date and time the message wasreceived 924, the priority of the message 926, the subject of themessage 928, and details of the message 930. The patient is able toselect an entry in the list 918 to view the received message and itscontents. The patient can also select an option 932 to delete one ormore of the messages.

The sent items option 908 displays a list of message sent from thepatient to a given recipient. The deleted option 910 displays a list ofdeleted messages to the patient. The appointments option 912 displays alist of messages sent by the patient for appointment requests and anyresponses to these messages. The medication refill option 914 displays alist of messages sent by the patient for medication refill requests andany responses to these messages. The referral request option 916displays a list of messages sent by the patient for referral requestsand any responses to these messages.

When the portal manager 118 detects that the patient has selected theappointments option 724 of the home area 744, the data presenter 204displays an appointments section 1002 to the patient in the interactiveenvironment 116 as shown in FIG. 10. The appointments section 1002displays a list 1004 comprising entries associated with one or moreappointments previously held (or currently held) by the patient.Appointment data such as appointment date, appointment time, visitreason, appointment location, and provider are displayed for each entryin the list 1004. The patient is also presented with one or more dataoptions such as an add option and a share option similar to the widgetsoptions discussed above. The add option allows the patient to addappointment information/records to his/her health-related data 126. Theshare option allows the patient to associate a sharable/confidentialproperty to all appointment entries or specific entries, as discussedabove. The share option can also allow the patient the designate one ormore parties to share the data with. The patient is also presented witha source type option 1006 and a visit date option 1008 similar to thosediscussed above with respect to FIG. 7.

The medications option 726 of the home area 744 presents the patientwith a medications section 1102 in the interactive environment 116 asshown in FIG. 11. A first portion 1104 of the medications section 1102displays a list 1106 of current and past medications for the patient.Information such as medicine name, quantity, expiration date, refills,pharmacy, notes, and details are provided to the patient for each entryin the list 1106. The patient is able to select the details area to viewadditional details for the associated entry. The patient is able toselect an option to edit the information for a given medication, and canalso delete an entry from the list 1106. The patient is also presentedwith a source type option 1108 and a visit date option 1110 similar tothose discussed above with respect to FIG. 7.

A second portion 1112 of the medications section 1102 displays a list1114 of pharmacies associated with the patient. Information such aspharmacy name, address, city, state, zip code, notes, and details isdisplayed to the patient. The patient is able to select the details areato view additional details for the associated entry in the list 1114.The patient is able to select an option to edit the information for agiven pharmacy, and can also delete and entry from the list 1106. Athird portion 1116 of the medications section 1102 is also displayed tothe patient. This portion 1116 allows the patient to search forpharmacies using various search criteria.

The referrals option 728 of the home area 744 displays a referralssection (not shown) to the patient in the interactive environment 116.The marketplace option 732 displays a marketplace section (not shown) tothe patient in the interactive environment 116. The marketplace sectionallows the patient to check drug interactions and perform other tasks.The manage doctors option 734 of the home area 744 presents the patientwith a manage doctors section 1202 in the interactive environment 116 asshown in FIG. 12. The manage doctors section 1202 comprises a list 1204of doctors currently associated with the patient. This list 1204displays information such as doctor name, type, office phone, whetherthe doctor is a primary care physician, and details to the patient. Thepatient is able to select the details area to view additional detailsfor the associated entry in the list 1204. The patient is able to selectan option to edit the information for a given doctor, and can alsodelete an entry from the list 1204. The patient is also presented withan add option 1206 that allows the patient to add one or more doctors tohis/her health-related data 126 or records 128.

The emergency contacts option 736 of the home area 744 presents thepatient with an emergency contacts section 1302 in the interactiveenvironment 116 as shown in FIG. 13. The emergency contacts section 1302comprises a list 1304 of emergency contacts currently associated withthe patient. This list 1304 displays information such as name, mobilenumber, address, email, city, state, country, and details to thepatient. The patient is able to select the details area to viewadditional details for the associated entry in the list 1344. Thepatient is able to select an option to edit the information for a givendoctor, and can also delete an entry from the list 1204. The patient isalso presented with an add option 1306 that allows the patient to addone or more emergency contacts to his/her health-related data 126 orrecords 128.

The share my records option 738 of the home area 744 presents thepatient with a share records section 1402 in the interactive environment116 as shown in FIG. 14. The share records section 1402 comprises aplurality of options such as a set passcode option 1404, a providerlabel section 1406, and a medical summary section 1408. The set passcodesection 1404 comprises an option 1414 that allows the patient to createa change a care provider pass code. This passcode allows the careprovider to log into the patient portal 114 and view the health-medicaldata 126 or records 128 associated with the patient. It should be notedthat, in one embodiment, any data 126 or records 128 marked by thepatient as being confidential/hidden are not displayed to the careprovider when he/she logs into the patient portal using the passcodecreated by the patient.

The provider label option 1406 displays a care provider label section1502 to the patient in the interactive environment 116 as shown in FIG.15. When this option 1406 is selected, the portal manager 1408automatically generates a label 1504 (or retrieves a previouslygenerated label) that can be printed out and given to the provider bythe patient, and/or automatically sent to the provider by the portal.The label 1504, in one embodiment comprises an identification 1506 ofthe patient; a login passcode 1508 associated with the patient, whichcan be different or the same as the patient's login password; and apasscode 1510 generated for the care provider. The label 1504 alsocomprises a URL 1512 for the patient portal 114, and instructions 1514on how to log into the portal 114. The care provider label section 1502also comprises an option 1516 that allows the patient to enter an emailaddress of their provider to have the portal 114 automatically send thelabel 1504 to the provider.

The medical summary option 1408 provided in the share my records section1402 displays an emergency records section 1602 to the patient and aprovider in the interactive environment 116 as shown in FIG. 16. Thissection 1602 displays personal and demographic information 1604associated with the patient and one or more emergency records options1606 to a recipient. In one embodiment, the patient or provider is ableto select a record option 1606 to have the corresponding recorddisplayed. For example, if the patient or provider selects the emergencycontact record option the corresponding emergency contact record 1608 isdisplayed within the interactive environment 116. In one embodiment,when a care provider logs into the portal 114 utilizing the informationon the provider label 1502, the emergency record information of FIG. 16is presented to the provider. However, other health-medical data 126 andrecords 128 can be displayed to a provider as well. Alternatively (or inaddition to), these emergency records are presented to a health careprovider in an emergency situation associated with the patient. In oneembodiment, only records/data associated with a sharable property areallowed to be viewed by parties other than the patient, as discussedabove.

The medical portfolio option 740 of the home area 744 displays a medicalportfolio section 1702 to the patient in the interactive environment 116as shown in FIG. 17. This section 1702 groups and presents thehealth-medical data 126 and records 128 associated with the patientbased on their assigned source type. For example, the data presenter 204displays a first area 1704 comprising health-medical data 126 andrecords 128 from integrated partners, a second area 1706 comprisinghealth-medical data 126 and records 128 from non-integrated entities,and a third area comprising health-medical data 126 and records 128provided by the patient. The integrated partner entries compriseinformation such as visit date, facility, physician, and reason forvisit. The patient is able to select an entry in this area 1704 to viewadditional details for the record/data represented by the entry.

The non-integrated entity entries comprise information such as uploaddata, physician, description, and comments. The patient is able toselect an entry in this area 1706 to view additional details for therecord/data represented by the entry. The patient entered entriescomprise information such as upload date, physician, description, andcomments. The patient is able to select an entry to view additionaldetails for the record/data represented by the entry. It should be notedthat each of these areas 1704, 1706, 1708 can comprise additionalinformation as well.

In one embodiment, each entry in the integrated partner area 1704, thenon-integrated entity area 1706, and the patient area 1708 can beassociated with a sharable or hidden (confidential) property similar tothat discussed above. The patient is able to select an option 1710 tochange the permission of the entry (and its health-medical data 126 orrecord 128) to either shared or hidden (confidential). A status field1712 displays the current sharable/hidden status of the entry and itshealth-medical data 126 or record 128. As discussed above,health-medical data 126 and records 128 associated with a sharedproperty are displayed to providers when they access the patient's data,receive messages comprising the patient's data, download documentscomprising the patient's data, and/or the like. However, health-medicaldata 126 and records 128 associated with a hidden/confidential propertyare not displayed to providers they access the patient's data, receivemessages comprising the patient's data, download documents comprisingthe patient's data, and/or the like. For example, when a provider logsinto the portal 114 to view a patient's data; when a message is beinggenerated with the patients date; or a document is being downloaded withthe patient's data, the data presenter 204 analyzes the health-medicaldata 126 and records 128 to be viewed, sent, or downloaded andidentifies the sharable/hidden flag associated therewith. Anyhealth-medical data 126 and records 128 with a hidden tag are preventedfrom being displayed or included within a message or document.

The digital file cabinet option 742 of home area 744 presents thepatient with a digital file cabinet section 1802 in the environment 116as shown in FIG. 18. This section 1802 displays one or more areas 1804,1806, 1808 associated with various types of documents. For example, FIG.18 shows a first area 1804 comprising general document information, asecond area 1806 comprising insurance policy document information, and athird area 1808 comprising professional advisor document information.The patient is able to select on an entry within one of these areas1804, 1806, 1808 and view the document associated with the entry. Thepatient can also select a permissions option 1810 to allow sharing ofthe document and its data to hide or keep the document and itsinformation confidential, as discussed above with respect to FIG. 17. Astatus indicator 1812 identifies whether a given document and itsinformation is sharable or hidden.

When the patient selects the view, download, and transmit option 710 ofthe home area 744 a view, download, and transmit section 1902 of theinteractive environment 116 is displayed to the patient as shown in FIG.19. In this section 1902, the patient selects a source type 1904 for thedate of interest, which can include a selection of all source types. Asdiscussed above, the source type identifies data as being eitherprovided by an integrated partner, a non-integrated entity, or thepatient herself. The patient can also be presented with a listcomprising each integrated partner and/or non-integrated entity forselection by the patient. An activity log 1906 is also provided to thepatient that displays the various activities performed by the patient ora provider (e.g., view health-medical data or records, transmithealth-medical data or records, etc.), the date and time of theactivity, and/or the like.

In one embodiment, the patient also provides visit criteria 1908specifying a given visit, range of visits, and/or all available visits.The patient further selects an a first option 1910 to view the record(s)corresponding to the source type and visit selections; a second option1912 to download the record(s); a third option 1914 to transmit therecord(s); and/or a fourth option 1916 to customize the record(s) forviewing, downloading of transmitting the record(s). This customizationoption allows the patient to select which data or sections in therecord(s) are viewed, downloaded, and/or transmitted. If the patientselects the option to transmit the data or record(s) the patientprovides or selects the messaging address 1918 of the recipient. Thepatient can also indicate whether the viewed, downloaded, and/ortransmitted record (or data) is to be a CCD 1920 in human-readableformat, or a CCDA XML based CCD 1922.

For example, if the patient selected a given provider from the sourcetype and a specific visit date, the data presenter 204 analyzes thehealth-medical data 126 or records associated with the patient toidentify a set of data or record(s) received from this specific providerfor the specified visit date. This identified record is then displayedto then presented to the patient on his/her display, downloaded to thepatient's system 108, and/or automatically transmitted to the recipientspecified by the patient. It should be noted that any portions of theidentified data 126 or record 128 marked as being hidden are notincluded in any displayed, sent, or downloaded data/record being viewedby any party other than the patient.

Operational Flow Diagrams

FIG. 20 is an operational flow diagram illustrating one example of anoverall process for managing access to patient health-relatedinformation in a health care patient portal. The operational flow ofFIG. 20 beings a step 2002 and flows directly to step 2004. The portalmanager 118, at step 2004, determines that a user has accessed thehealth care patient portal 114. The portal manager 118, at step 2006,identifies a set of electronic health-related records 128 associatedwith the user. The portal manager 118, at step 2008, identifies a sourceidentifier associated with each of the set of electronic health-relatedrecords 128. The source identifier is associated with an entity thatprovided the electronic health-related record to the health care patientportal 114.

The portal manager 118, at step 2010, determines a sharing statusassociated with each of the set of electronic health-related records128. The sharing status indicates that the associated electronichealth-related record 128 is one of sharable and non-sharable with anentity other than the user. The portal manager 118, at step 2012,presents the set of electronic health-related records 128 to the user inthe health care patient portal 114. At least one of the set ofelectronic health-related records 128 is presented with the sourceidentifier and the sharing status associated with the at least one ofthe set of electronic health-related records 128. The control flow exitsat step 2014.

FIG. 21 is an operational flow diagram illustrating another example ofan overall process for managing access to patient health-relatedinformation in a health care patient portal. The operational flow ofFIG. 21 beings a step 2102 and flows directly to step 2104. The portalmanager 118, at step 2104, receives a set of electronic health-relatedrecords 128 associated with at least one user from at least one source.The portal manager 118, at step 2106, assigns a source identifier toeach of the set of electronic health-related records 128 based onreceiving the records 128. The source identifier identifies the sourceas one of the user, an entity integrated with the health care patientportal, and an entity that fails to be integrated with the health carepatient portal.

The portal manager 118, at step 2108, determines that the user hasaccessed the health care patient portal 114. The portal manager 118, atstep 2110, retrieves the set of electronic health-related records 128associated with the user. The portal manager 118, at step 2112,identifies the source identifier associated with each of the set ofhealth-related records. The portal manager 118, at step 2114, determinesa sharing status associated with each of the set of health-relatedrecords 128. The sharing status indicates that the associated electronichealth-related record 128 is one of sharable and non-sharable with anentity other than the user. The portal manager 118, at step 2116,presents the set of electronic health-related records 128 to the user inone or more user-customizable widgets within the health care patientportal 114. At least one of the set of electronic health-related records128 is presented with the source identifier and the sharing statusassociated with the at least one of the set of electronic health-relatedrecords 128. The control flow exits at step 2118.

Information Processing System

FIG. 22 shows a block diagram illustrating an information processingsystem 2200 that can be utilized in various embodiments of the presentdisclosure such as the information processing system 102 shown inFIG. 1. The information processing system 2202 is based upon a suitablyconfigured processing system configured to implement one or moreembodiments of the present disclosure. Any suitably configuredprocessing system can be used as the information processing system 2202in embodiments of the present disclosure. The components of theinformation processing system 2202 can include, but are not limited to,one or more processors or processing units 2204, a system memory 2206,and a bus 2208 that couples various system components including thesystem memory 2206 to the processor 2204.

The bus 2208 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. By way of example, and notlimitation, such architectures include Industry Standard Architecture(ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA)bus, Video Electronics Standards Association (VESA) local bus, andPeripheral Component Interconnects (PCI) bus.

Although not shown in FIG. 22, the main memory 2206 includes at thepatient portal 114, its components including the portal manager 118, theuser profiles 120, the facility profiles 122, the subscriber profiles124, and the health/medical data 126 and records 128 shown in FIG. 1.The portal manager 118 can reside within the processor 2204, or be aseparate hardware component. The system memory 2206 can also includecomputer system readable media in the form of volatile memory, such asrandom access memory (RAM) 2210 and/or cache memory 2212. Theinformation processing system 2202 can further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, a storage system 2214 can be provided forreading from and writing to a non-removable or removable, non-volatilemedia such as one or more solid state disks and/or magnetic media(typically called a “hard drive”). A magnetic disk drive for readingfrom and writing to a removable, non-volatile magnetic disk (e.g., a“floppy disk”), and an optical disk drive for reading from or writing toa removable, non-volatile optical disk such as a CD-ROM, DVD-ROM orother optical media can be provided. In such instances, each can beconnected to the bus 2208 by one or more data media interfaces. Thememory 2206 can include at least one program product having a set ofprogram modules that are configured to carry out the functions of anembodiment of the present disclosure.

Program/utility 2216, having a set of program modules 2218, may bestored in memory 2206 by way of example, and not limitation, as well asan operating system, one or more application programs, other programmodules, and program data. Each of the operating system, one or moreapplication programs, other program modules, and program data or somecombination thereof, may include an implementation of a networkingenvironment. Program modules 2218 generally carry out the functionsand/or methodologies of embodiments of the present disclosure.

The information processing system 2202 can also communicate with one ormore external devices 2220 such as a keyboard, a pointing device, adisplay 2222, etc.; one or more devices that enable a patient tointeract with the information processing system 2202; and/or any devices(e.g., network card, modem, etc.) that enable computer system/server2202 to communicate with one or more other computing devices. Suchcommunication can occur via I/O interfaces 2224. Still yet, theinformation processing system 2202 can communicate with one or morenetworks such as a local area network (LAN), a general wide area network(WAN), and/or a public network (e.g., the Internet) via network adapter2226. As depicted, the network adapter 2226 communicates with the othercomponents of information processing system 2202 via the bus 2208. Otherhardware and/or software components can also be used in conjunction withthe information processing system 2202. Examples include, but are notlimited to: microcode, device drivers, redundant processing units,external disk drive arrays, RAID systems, tape drives, and data archivalstorage systems.

Non-Limiting Examples

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be embodied as a system, method, or computer programproduct. Accordingly, aspects of the present disclosure may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit”, “module”, or “system.”

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers, and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. Also, the phrase “such as” is not intended to limit thedisclosure to any particular item being referred to. It will be furtherunderstood that the terms “comprises” and/or “comprising” when used inthis specification, specify the presence of stated features, integers,steps, operations, elements, and/or components, but do not preclude thepresence or addition of one or more other features, integers, steps,operations, elements, components, and/or groups thereof.

The description of the present disclosure has been presented forpurposes of illustration and description, but is not intended to beexhaustive or limited to the invention in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the invention.The embodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A method for managing access to patienthealth-related information in a health care patient portal, the methodcomprising: determining, by an information processing system comprisinga health care patient portal, that a user has accessed the health carepatient portal; identifying a set of electronic health-related recordsassociated with the user; identifying a source identifier associatedwith each of the set of electronic health-related records, wherein thesource identifier is associated with an entity that provided theelectronic health-related record to the health care patient portal;determining a sharing status associated with each of the set ofelectronic health-related records, wherein the sharing status indicatesthat the associated electronic health-related record is one of sharableand non-sharable with an entity other than the user; and presenting theset of electronic health-related records to the user in the health carepatient portal, wherein at least one of the set of electronichealth-related records is presented with the source identifier and thesharing status associated with the at least one of the set of electronichealth-related records.
 2. The method of claim 1, wherein the sourceidentifier identifies the entity as being one of the user, an entityintegrated with the health care patient portal, and an entity that failsto be integrated with the health care patient portal.
 3. The method ofclaim 1, further comprising: receiving, from the user, a request tochange the sharing status of at least one of the set of electronichealth-related records; and updating the sharing status of the least oneof the set of electronic health-related records based on the requestreceived from the user.
 4. The method of claim 1, further comprising:receiving a request from the user to provide access for a health careprovider to one or more electronic health-related records associatedwith the user; and automatically generating, based on receiving therequest, authentication credentials for the health care provider,wherein the authentication credentials comprise a health care patientportal login username, a health care patient portal login password, andan identifier associated with the user.
 5. The method of claim 4,further comprising: transmitting the authentication credentials to thehealth care provider.
 6. The method of claim 1, further comprising:determining that an entity other than the user has accessed the healthcare patient portal to view electronic health-related records associatedwith the user; identifying, based on the determining, the set ofelectronic health-related records associated with the user; determininga sharing status associated with each of the set of electronichealth-related records; based on at least a first electronichealth-related record in the set of electronic health-related recordsbeing in a shared state, presenting the at least first electronichealth-related record to the entity in the health care patient portal;and based on at a least a second electronic health-related record in theset of electronic health-related records being in a hidden state,preventing the at least second electronic health-related record frombeing presented to the entity in the health care patient portal.
 7. Themethod of claim 1, further comprising: receiving, by the health carepatient portal, a set of electronic health-related informationassociated with the user from a source; identifying, based on thereceiving, that the source is one of the user, an entity integrated withthe health care patient portal, and an entity that fails to beintegrated with the health care patient portal; and storing the set ofelectronic health-related information with a source identifier, whereinthe source identifier indicates that the set of set of electronichealth-related information was received from one of the user, an entityintegrated with the health care patient portal, and an entity that failsto be integrated with the health care patient portal.
 8. The method ofclaim 1, wherein presenting the set of electronic health-related recordscomprises presenting the set of electronic health-related records withinin one or more customizable widgets within the health care patientportal.
 9. The method of claim 1, further comprising: receiving a set ofelectronic health-related information from at least one of the user, ahealth care provider associated with the user, and an electronic healthmanagement system associated with a health care provider of the user,wherein the set of electronic health-related information comprise atleast one of structured data and unstructured data.
 10. The method ofclaim 9, wherein receiving the set of electronic health-relatedinformation comprises receiving one of a continuity of care document, acontinuity of care record, and an unstructured document based on aclinical document architecture.
 11. An information processing system formanaging access to patient health-related information in a health carepatient portal, the information processing system comprising: memory; aprocessor communicatively coupled to the memory; a health care patientportal; and a portal manager, wherein the portal manager is configuredto perform a method comprising: receiving, from a at least one source, aset of electronic health-related records associated with at least oneuser; assigning, based on the receiving, a source identifier to each ofthe set of electronic health-related records identifying the source asone of the user, an entity integrated with the health care patientportal, and an entity that fails to be integrated with the health carepatient portal; determining that the user has accessed the health carepatient portal; retrieving the set of electronic health-related recordsassociated with the user; identifying the source identifier associatedwith each of the set of health-related records; determining a sharingstatus associated with each of the set of health-related records,wherein the sharing status indicates that the associated electronichealth-related record is one of sharable and non-sharable with an entityother than the user; and presenting the set of electronic health-relatedrecords to the user in one or more user-customizable widgets within thehealth care patient portal, wherein at least one of the set ofelectronic health-related records is presented with the sourceidentifier and the sharing status associated with the at least one ofthe set of electronic health-related records.
 12. A computer programstorage product for managing access to patient health-relatedinformation in a health care patient portal, the computer programstorage product comprising instructions configured to perform a methodcomprising: determining, by an information processing system comprisinga health care patient portal, that a user has accessed the health carepatient portal; identifying a set of electronic health-related recordsassociated with the user; identifying a source identifier associatedwith each of the set of electronic health-related records, wherein thesource identifier is associated with an entity that provided theelectronic health-related record to the health care patient portal;determining a sharing status associated with each of the set ofelectronic health-related records, wherein the sharing status indicatesthat the associated electronic health-related record is one of sharableand non-sharable with an entity other than the user; and presenting theset of electronic health-related records to the user in the health carepatient portal, wherein at least one of the set of electronichealth-related records is presented with the source identifier and thesharing status associated with the at least one of the set of electronichealth-related records.
 13. The computer program storage product ofclaim 12, wherein the source identifier identifies the entity as beingone of the user, an entity integrated with the health care patientportal, and an entity that fails to be integrated with the health carepatient portal.
 14. The computer program storage product of claim 12,wherein the method further comprises: receiving, from the user, arequest to change the sharing status of at least one of the set ofelectronic health-related records; and updating the sharing status ofthe least one of the set of electronic health-related records based onthe request received from the user.
 15. The computer program storageproduct of claim 12, wherein the method further comprises: receiving arequest from the user to provide access for a health care provider toone or more electronic health-related records associated with the user;and automatically generating, based on receiving the request,authentication credentials for the health care provider, wherein theauthentication credentials comprise a health care patient portal loginusername, a health care patient portal login password, and an identifierassociated with the user.
 16. The computer program storage product ofclaim 12, wherein the method further comprises: determining that anentity other than the user has accessed the health care patient portalto view electronic health-related records associated with the user;identifying, based on the determining, the set of electronichealth-related records associated with the user; determining a sharingstatus associated with each of the set of electronic health-relatedrecords; based on at least a first electronic health-related record inthe set of electronic health-related records being in a shared state,presenting the at least first electronic health-related record to theentity in the health care patient portal; and based on at a least asecond electronic health-related record in the set of electronichealth-related records being in a hidden state, preventing the at leastsecond electronic health-related record from being presented to theentity in the health care patient portal.
 17. The computer programstorage product of claim 12, wherein the method further comprises:receiving, by the health care patient portal, a set of electronichealth-related information associated with the user from a source;identifying, based on the receiving, that the source is one of the user,an entity integrated with the health care patient portal, and an entitythat fails to be integrated with the health care patient portal; andstoring the set of electronic health-related information with a sourceidentifier, wherein the source identifier indicates that the set of setof electronic health-related information was received from one of theuser, an entity integrated with the health care patient portal, and anentity that fails to be integrated with the health care patient portal.18. The computer program storage product of claim 12, wherein presentingthe set of electronic health-related records comprises presenting theset of electronic health-related records within in one or morecustomizable widgets within the health care patient portal.
 19. Thecomputer program storage product of claim 12, wherein the method furthercomprises: receiving a set of electronic health-related information fromat least one of the user, a health care provider associated with theuser, and an electronic health management system associated with ahealth care provider of the user, wherein the set of electronichealth-related information comprise at least one of structured data andunstructured data.
 20. The computer program storage product of claim 19,wherein receiving the set of electronic health-related informationcomprises receiving one of a continuity of care document, a continuityof care record, and an unstructured document based on a clinicaldocument architecture.